fix(@angular/ssr): validate host headers to prevent header-based SSRF by alan-agius4 · Pull Request #32516 · angular/angular-cli

alan-agius4 · 2026-02-19T11:02:03Z

This change introduces strict validation for Host, X-Forwarded-Host, X-Forwarded-Proto, and X-Forwarded-Port headers in the Angular SSR request handling pipeline, including CommonEngine and AngularAppEngine.

Previously, the application engine constructed the base URL for server-side rendering using these headers without validation. This could allow an attacker to manipulate the headers to steer relative HttpClient requests to arbitrary internal or external hosts (SSRF).

The validation rules are:

Host and X-Forwarded-Host headers are validated against an authorized allowlist.
Host and X-Forwarded-Host headers cannot contain path separators.
X-Forwarded-Port header must be numeric.
X-Forwarded-Proto header must be http or https.

Requests with invalid or disallowed headers will now log an error and fallback to Client-Side Rendering (CSR). In a future major version, these requests will be rejected with a 400 Bad Request.

Note: Most cloud providers and CDNs already validate these headers before the request reaches the text application, but this change adds an essential layer of defense-in-depth.

AngularAppEngine Users:
To exclude safe hosts from validation, configure the allowedHosts option in angular.json to include all domain names where your application is deployed.

Example configuration in angular.json:

"architect": {
  "build": {
    "options": {
      "security": {
        "allowedHosts": ["example.com", "*.trusted-example.com"]
      }
    }
  }
}

or

const appEngine = new AngularAppEngine({
  allowedHosts: ["example.com", "*.trusted-example.com"]
})

const appEngine = new AngularNodeAppEngine({
  allowedHosts: ["example.com", "*.trusted-example.com"]
})

CommonEngine Users:
If you are using CommonEngine, you must now provide the allowedHosts option when initializing or rendering your application.

Example:

const commonEngine = new CommonEngine({
  allowedHosts: ["example.com", "*.trusted-example.com"]
});

The application also respects NG_ALLOWED_HOSTS (comma-separated list) and HOSTNAME environment variables for authorizing hosts.

dgp1130

Left some general suggestions, but nothing major. Feel free to ignore or come back to any of these later rather than treating them as blocking this PR. The two main things to confirm are really just:

Should we commit to ${HOSTNAME} / ${NG_ALLOWED_HOSTS} right now, or come back later?
Should we error when allowedHosts is configured and we receive a request for a disallowed host, to be up front about a misconfiguration rather than silently deoptimizing?

packages/angular/ssr/node/src/common-engine/common-engine.ts

dgp1130 · 2026-02-19T16:56:12Z

packages/angular/ssr/node/src/common-engine/common-engine.ts

+        let document = opts.document;
+        if (!document && opts.documentFilePath) {
+          document = await this.getDocument(opts.documentFilePath);
+        }


Question: What's the purpose of reading the document here? Why do we need this?

Document in this is case is the index.html which we need to serve it to render CSR.

packages/angular/ssr/node/src/common-engine/common-engine.ts

dgp1130 · 2026-02-19T17:00:39Z

packages/angular/ssr/node/src/common-engine/common-engine.ts

+    const envNgAllowedHosts = processEnv['NG_ALLOWED_HOSTS'];
+    if (envNgAllowedHosts) {
+      const hosts = envNgAllowedHosts.split(',');
+      for (const host of hosts) {
+        const hostTrimmed = host.trim();
+        if (hostTrimmed) {
+          allowedHosts.add(hostTrimmed);
+        }
+      }
+    }


Consider: Do you want to tackle this now, as something we'll probably have to support for a few versions, or leave it off and require allowedHosts to be specified in the build options in the short term until we come back to this in v22+?

I agree this is probably a good direction, but I'm wondering if it might benefit from more discussion, and I don't think we need to have it right now. Would it make sense to hold off before committing to a new public API here?

My reason for this is that you'd be able to provide the allowedHost at runtime where using env variables is not an option. For instance in worker context.

If you feel we should hold this off, I am fine with this. Please let me know.

packages/angular/ssr/node/src/app-engine.ts

packages/angular/ssr/src/utils/validation.ts

dgp1130 · 2026-02-19T17:13:22Z

packages/angular/ssr/src/utils/validation.ts

+
+              const key = name.toLowerCase();
+              if (HOST_HEADERS_TO_VALIDATE.has(key)) {
+                verifyHostAllowed(key, value, allowedHosts);


Observation: I could see this failing some apps who iterate through headers like:

for (const [name, value] of Object.entries(req.headers)) { if (!name.startsWith('x-myapp-*')) continue; doSomethingWith(name, value); }

In this case, they're not really using host or x-forwarded-host, but they will read the values and probably trigger the CSR deopt. I don't think there's anything we can meaningfully do about this, but pointing out the case of iterating through all the headers which isn't too uncommon.

They will actually not trigger the CSR deopt. in this case they will not be validated.

packages/angular/ssr/src/app-engine.ts

packages/angular/ssr/node/src/common-engine/common-engine.ts

packages/angular/ssr/node/src/app-engine.ts

AndrewKushnir · 2026-02-20T05:06:50Z

packages/angular/ssr/src/utils/validation.ts

+    }
+  }
+
+  const xForwardedPort = getFirstHeaderValue(headers.get('x-forwarded-port'));


Quick question: do we normalize headers and lowercase the names earlier in the code?

No we do not normalize headers names, the headers.get() is case insensitive.

packages/angular/ssr/src/app-engine.ts

This change introduces strict validation for `Host`, `X-Forwarded-Host`, `X-Forwarded-Proto`, and `X-Forwarded-Port` headers in the Angular SSR request handling pipeline, including `CommonEngine` and `AngularAppEngine`. Previously, the application engine constructed the base URL for server-side rendering using these headers without validation. This could allow an attacker to manipulate the headers to steer relative `HttpClient` requests to arbitrary internal or external hosts (SSRF). The validation rules are: - `Host` and `X-Forwarded-Host` headers are validated against a strict allowlist. - `Host` and `X-Forwarded-Host` headers cannot contain path separators. - `X-Forwarded-Port` header must be numeric. - `X-Forwarded-Proto` header must be `http` or `https`. Requests with invalid or disallowed headers will now log an error and fallback to Client-Side Rendering (CSR). In a future major version, these requests will be rejected with a 400 Bad Request. Note: Most cloud providers and CDNs already validate these headers before the request reaches the text application, but this change adds an essential layer of defense-in-depth. **AngularAppEngine Users:** To exclude safe hosts from validation, configure the `allowedHosts` option in `angular.json` to include all domain names where your application is deployed. Example configuration in `angular.json`: ```json "architect": { "build": { "options": { "security": { "allowedHosts": ["example.com", "*.trusted-example.com"] } } } } ``` or ```ts const appEngine = new AngularAppEngine({ allowedHosts: ["example.com", "*.trusted-example.com"] }) const appEngine = new AngularNodeAppEngine({ allowedHosts: ["example.com", "*.trusted-example.com"] }) ``` **CommonEngine Users:** If you are using `CommonEngine`, you must now provide the `allowedHosts` option when initializing or rendering your application. Example: ```typescript const commonEngine = new CommonEngine({ allowedHosts: ["example.com", "*.trusted-example.com"] }); ``` The application also respects `NG_ALLOWED_HOSTS` (comma-separated list) environment variable for authorizing hosts.

alan-agius4 · 2026-02-20T13:56:14Z

Left some general suggestions, but nothing major. Feel free to ignore or come back to any of these later rather than treating them as blocking this PR. The two main things to confirm are really just:

Should we commit to ${HOSTNAME} / ${NG_ALLOWED_HOSTS} right now, or come back later?

I removed ${HOSTNAME}, I think ${NG_ALLOWED_HOSTS} can be useful to support this dynamically in environments that support Node.js

Should we error when allowedHosts is configured and we receive a request for a disallowed host, to be up front about a misconfiguration rather than silently deoptimizing?

Updated the logic to do this.

…ed SSRF

alan-agius4 added the target: minor This PR is targeted for the next minor release label Feb 19, 2026

angular-robot bot added the area: @angular/ssr label Feb 19, 2026

alan-agius4 added target: rc This PR is targeted for the next release-candidate and removed target: minor This PR is targeted for the next minor release area: @angular/ssr labels Feb 19, 2026

alan-agius4 force-pushed the security-validate-main branch from a44aef7 to 8778533 Compare February 19, 2026 11:26

angular-robot bot added the area: @angular/ssr label Feb 19, 2026

alan-agius4 force-pushed the security-validate-main branch 5 times, most recently from 757306a to de79ce3 Compare February 19, 2026 12:15

alan-agius4 requested a review from dgp1130 February 19, 2026 13:15

alan-agius4 added action: review The PR is still awaiting reviews from at least one requested reviewer labels Feb 19, 2026

alan-agius4 marked this pull request as ready for review February 19, 2026 13:15

alan-agius4 mentioned this pull request Feb 19, 2026

fix(@angular/ssr): validate host headers to prevent header-based SSRF [main] #32499

Closed

alan-agius4 force-pushed the security-validate-main branch 4 times, most recently from faf18cf to aa6ee92 Compare February 19, 2026 14:49

dgp1130 approved these changes Feb 19, 2026

View reviewed changes

AndrewKushnir approved these changes Feb 20, 2026

View reviewed changes

alan-agius4 force-pushed the security-validate-main branch 6 times, most recently from da7a6aa to 301a633 Compare February 20, 2026 11:17

alan-agius4 force-pushed the security-validate-main branch 2 times, most recently from 9feb3c7 to b0b1a97 Compare February 20, 2026 11:46

alan-agius4 mentioned this pull request Feb 20, 2026

fix(@angular/ssr): prevent open redirect via X-Forwarded-Prefix header #32521

Open

alan-agius4 force-pushed the security-validate-main branch 2 times, most recently from 50ff773 to fe3fbba Compare February 20, 2026 14:10

alan-agius4 requested a review from dgp1130 February 20, 2026 15:08

alan-agius4 force-pushed the security-validate-main branch from fe3fbba to e38778a Compare February 20, 2026 15:53

fixup! fix(@angular/ssr): validate host headers to prevent header-bas…

a9a660f

…ed SSRF

alan-agius4 force-pushed the security-validate-main branch from e38778a to a9a660f Compare February 20, 2026 15:54

Conversation

alan-agius4 commented Feb 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dgp1130 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

alan-agius4 commented Feb 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Comments

alan-agius4 commented Feb 19, 2026 •

edited

Loading